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I. REAL PARTY IN INTEREST 

The real party in interest is the assignee, Tellme 
Networks, Inc., pursuant to the Assignment recorded in the U.S. 
Patent and Trademark Office on January 22, 2001 on Reel 011505, 
Frame 0570. 

II, RELATED APPEALS AND INTERFERENCES 

Based on information and belief, there are no other appeals 
or interferences that could directly affect or be directly 
affected by or have a bearing on the decision by the Board of 
Patent Appeals in the pending appeal. 

III. STATUS OF CLAIMS 

Claims 1-17 are pending. Claims 1-17 stand rejected. 
In the present paper, rejected Claims 1-17 are appealed. 
Pending Claims 1-17 are listed in the Claims Appendix. 

IV. STATUS OF AMENDMENTS 

Claims 15-17 were amended in this application after a first 
Office Action. No claims were amended after the Final Office 
Action dated February 18, 2005. 
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V, SUMMARY OF CLAIMED SUBJECT MATTER 

As described in the Summary of the Invention, page 5, lines 
12-23 : 

A method and apparatus for linking a web based 
account to a phone based account is described. The 
method avoids the need to directly reveal account 
information, e.g. username/password, about one 
account to the provider of the other. The linking 
occurs on the web in one embodiment, with a user's 
browser being redirected from the web site to the 
web site of the provider of the voice service. The 
redirection URL will include account linking 
information. Once the user identifies herself to 
the web site of the provider of the voice service, 
the linking information can be stored in the user's 
phone account as a cookie. 

When the user accesses the voice service over the 
phone, her telephone identifying information can be 
used to identify her profile. When she visits the 
phone application corresponding to the web site, 
the cookie— now including linking information— can be 
passed to the application to identify the 
appropriate web account . 

As further taught in the Specification, page 8, lines 1-11: 

embodiments of the invention allow applications 
provided by multiple legal entities ... to provide 
services to users via phone applications hosted 
on, or through, the voice portal while allowing 
state information to be stored on a per-user 
profile basis. Further, embodiments of the 
invention limit access by an application provided 
by a first legal entity to access the stored 
state information set by an application provided 
by a second legal entity. These features (1) 
protect user privacy by reducing the need to pass 
the telephone identifying information among 
different legal entities; (2) segregate the 
information a user provides to one legal entity 
from information provided to another legal 
entity, e.g. state information provided to 
[Company 1] does not get presented to [Company 2] 
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and vice -versa; and (3) provide for a uniform 
interface for application programmers to store 
state information in their voice portal 
applications . 

Fig. 1 (shown below) illustrates an exemplary system that 
can provide personalized content to users of telephones 
according to telephone identifying information. This 
personalized content can include Internet based information from 
various entities over the telephone. Specification, page 11, 
lines 20-23. 
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shared database includes a profile 152 (for the 
person 140) . 

Specification, page 12, lines 2-7 



Both the web server 108 and the voice portal 
110 are capable of communicating with the shared 
database 112 to register users and build profiles, 
e.g. the profile 152 for the person 140. The 
database 112 stores profiles for each user based on 
an association between one or more pieces of 
telephone identifying information and a particular 
user. Thus, the database may have a profile for a 
user Sarah Smith that is keyed to her home 
telephone number, e.g. 650-493-#### . Additionally, 
Sarah could associate other numbers, e.g. work, 
cellular, etc., with her profile either implicitly, 
e.g. by repeatedly calling the voice portal 110 
from those numbers, or explicitly, e.g. by adding 
those numbers to the system directly. 

The entity 128 most generally represents one 
or more individuals, businesses, legal entities, 
and/or other entities, that operate over the 
Internet 106, e.g. by providing a web site such 
as the web site 130. The operated web site 130 
may be informational and/or commerce based. In 
this example, the entity 128 will be an online 
merchant that operates the web site 13 0 at the 
uniform resource locator (URL) 

<http : //www. onlinemerchant . com/> . Consumers, such 
as the person 140, who visit the entity's web 
site to make purchases may create online 
accounts, e.g. the web account 150; frequently 
using a username-password style form of 
identification ... The entity 128 can establish its 
web site 130 and phone site 132 using one or more 
available computer systems and programs for 
supporting the same. According to some 
embodiments of the invention, the programs for 
the phone site 132 can be hosted on one or more 
standard hypertext transfer protocol (HTTP) 
servers for access by the voice portal 110 over 
the Internet 106. 

Page 14, line 17 to page 15, line 6. 
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Linking a web based account (e.g. web account 150) to a 
phone account (e.g. profile 152) can begin with the person 140 
navigating to the web site 130 with the computer 102. 
Specification, page 15, lines 14-15. One or more of the web 
pages presented on the display of the computer 102 may offer to 
"phone" enable the user's account. Specification, page 15, 
lines 15-17. For example, if the entity 128 is an online 
merchant, then a banner ad or text might invite the user to 
"Click here to phone enable your account for access from 
Tellme" , "Want to place orders by phone? Click here to sign 
up.", etc. Specification, page 15, lines 17-19. 

Assuming the user accepts the offer, the user's browser is 
redirected to another location (e.g. the web server 108 of the 
operator of the voice portal 110). Specification, page 16, 
lines 9-10. During this redirection, several arguments will be 
passed including: a linking code generated by the entity 128 to 
uniquely identify the web account 150 and a return URL that 
identifies what page on the web site 13 0 to send the user after 
the linking code is associated with the user's phone account. 
Specification, page 16, lines 18-23. 



Note that if the web site 108 has already 
stored an identifying cookie with the user's web 
browser (e.g. on their computer 102), it may be 
unnecessary for the user to take any direct 
action to unlock their phone account. The user's 
web browser would visit the web new location, the 
cookie in the user's web browser would identify 
the user to the voice portal and the linking code 
could then be stored and the user sent back to 
the return URL without any user actions aside 
from the initial click. According to one 
preferred embodiment, the voice portal 110 (via 
its web server 108) stores one or more 
identifying cookies on the computer 102 of the 
person 140 to eliminate the need for a manual log 
in as part of step 230. This supports single 
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action (or "one click") account linking as users 
need only perform a single direct action, e.g. 
click their mouse, to link their web account to 
their phone account (this assumed that offers of 
step 200 are only presented to users logged into 
the web site 130) . 

Specification, page 17, lines 6-17. 

When the user has successfully entered the information, the 
linking code can be stored in a cookie within the profile 152 . 
Specification, page 17, lines 18-19. After the cookie is 
stored, the browser on the user's computer 102 can be redirected 
to the return URL provided, e.g. sent back to an appropriate 
location within the web site 130. Specification, page 17, lines 
21-23. At this point, the user's web account for entity 128 is 
configured for access via the phone. Specification, page 17, 
lines 23-24. 

Using the linked web account (e.g. the web account 150) 
from the voice portal 110 starts by a user calling the voice 
portal 110 with a telephone (e.g. the telephone 100). 
Specification, page 18, lines 2-3 and 9-10. After the voice 
portal 110 identifies the user, the user's profile (e.g. the 
profile 152) is unlocked. Specification, page 18, lines 12-13. 
In one embodiment, this identification can include using 
telephone identifying information. Specification, page 18, 
lines 14-17. Then, the user can access the phone site 132 of 
the entity 132, thereby causing the voice portal 110 to begin 
execution of one or more programs from the phone site 132. 
Specification, page 18, lines 18-20. The linking code can be 
transmitted to the entity 12 8 as a part of one or more standard 
HTTP requests. Specification, page 19, lines 1-2. 

In one embodiment, the account linking approach can be 
extended to allow sharing of wallet information, or other 
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personal information, from a web site to the operator of a voice 
portal. Specification, page 19, lines 18-20. 

Referring to Claim 1 and its dependent claims, the first, 
second, and third computers could refer to the computer 102, the 
web server 108, and the web site 130, respectively, of Fig. 1. 

Referring to Claim 9 and its dependent claims, the first 
and second computers could refer to the web server 108 and the 
web site 130, respectively, of Fig. 1. 

Referring to Claim 14, the apparatus, the first computer, 
and the third computer could refer to the voice portal 110/web 
server 108, the computer 102, and the web site 130, 
respectively, of Fig. 1. 

Referring to Claim 15 and its dependent claims, the first 
and second computer could refer to the web server 108 and the 
web site 130, respectively, of Fig. 1. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The following issues are presented to the Board of Appeals for 
decision: 

(A) Whether the objection to Claim 11 is improper. 

(B) Whether Claims 1-17 are patentable under 35 U.S.C. 112, first 
and second paragraphs. 

(C) Whether Claims 1-3, 5-6, 8-9, and 11-14 are patentable under 
35 U.S.C. 103(a) over U.S. Patent 6,065,120 (Larsen) in view of 
U.S. Patent 6,701,366 (Kallas) . 

(D) Whether Claim 4 is patentable under 35 U.S.C. 103(a) over 
Laursen in view of Kallas and further in view of Safari Tech 
Books Online Java 2 in 21 Days (Java2) . 
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(E) Whether Claims 7 and 15-17 are patentable under 35 U.S.C. 
103 (a) over Laursen in view of Kallas and further in view of 
Google's "A Generalized Wallet Architecture" (Google). 

(F) Whether Claim 10 is patentable under 35 U.S.C. 103(a) over 
Laursen in view of Kallas and further in view of Safari Tech 
Books Online "Using HTML 4, XML, and Java 1.2" (Safari). 

VIII, ARGUMENTS 

A. The objection to Claim 11 is improper 

Applicants respectfully submit that the sentence in Claim 
11 is complete. Claim 11 depends from Claim 9, which recites in 
part, "automatically providing a subset of the plurality of 
cookies to the application ... wherein the subset of the plurality 
of cookies includes at least one cookie including a linking 
code" (emphasis added) . Claim 11 recites "further comprising 
automatically removing the at least one cookie including the 
linking code from the plurality of cookies after the 
automatically providing" (emphasis added) . Thus, Claim 11 
recites limitations introduced in Claim 9. Therefore, 
Applicants submit that the objection to Claim 11 is improper. 

B. Claims 1-17 are patentable under 35 U.S.C. 112, first and 
second paragraphs 

Claims 1-17 are rejected as failing to comply with the 
written description requirement. Specifically, the Office 
Action states that the recited first, second, and third 
computers are not described in the Specification. Claims 1-17 
are also rejected as failing to comply with the enablement 
requirement. Specifically, the Office Action states that the 
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first, second, and third computers are incapable of 
communicating with each other. Claims 3 and 4 are rejected as 
failing to comply with the enablement requirement. 
Specifically, the Office Action states that the "single click" 
is an impossibility. Claims 1-17 are rejected as being 
indefinite. Specifically, the Office Action states that the 
recited first computer can be interpreted as a phone, a voice 
portal, a web server, or a mobile device with web capabilities, 
thereby making this term indefinite. Applicants traverse these 
112 rejections. 

The exemplary passages of the Specification indicated above 
in "V. SUMMARY OF CLAIMED SUBJECT MATTER" clearly teach the 
recited computers. Applicants note that the first, second, and 
third computers were also recited in the original claims, which 
form part of the Specification (e.g. see, MPEP 608.01 (i) (a), 
"The specification must conclude with a claim particularly 
pointing out and distinctly claiming the subject matter" and 
MPEP 608.01 (i) (d) (1), "The claim or claims must conform to the 
invention as set forth in the remainder of the specification."). 
Therefore, the first, second, and third computers are clearly 
described in the Specification. 

Regarding the enablement requirement for Claims 1-17, the 
Office Action questions if the "first computer" is a plain old 
phone, how that phone could make a connection request to a 
"second computer" (which can be a web server or personal 
computer) without any adapter. Applicants believe that this 
question indicates a misunderstanding of what is being claimed. 
That is, Claims 1 and 14 refer to linking a web based account to 
a phone based account, whereas Claim 9 refers to accessing a web 
based account over a telephone interface and Claim 15 refers to 
obtaining customer information over a telephone interface. 
Applicants submit that as shown by the exemplary passages of the 
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Specification indicated above in "V. SUMMARY OF CLAIMED SUBJECT 
MATTER" the computers are capable of communicating with each 
other. Therefore, Claims 1-17 contain subject matter that was 
described in the Specification in such a way as to enable one 
skilled in the art to make and/or use the invention. 

Regarding the enablement requirement for Claims 3 and 4, 
the Specification, e.g. exemplary passages indicated above in 
"V. SUMMARY OF CLAIMED SUBJECT MATTER", clearly teach the single 
click limitation. For example, see the passage quoted from the 
Specification, page 17, lines 6-17. Therefore, Claims 3 and 4 
contain subject matter that was described in the Specification 
in such a way as to enable one skilled in the art to make and/or 
use the invention. 

Regarding Claims 1-17 as being indefinite, the 

Specification teaches at page 13, line 21 to page 14, line 3: 

The computer 102 is a computer such as a 
personal computer, a thin client computer, a 
server computer, a handheld computer, a set top 
box computer, and/or some other type of visual 
web browsing device. The computer 102 is coupled 
in communication with the Internet 106, e.g. by a 
dial-up connection, a digital subscriber loop 
(DSL) , a cable modem, and/or some other type of 
connection. This allows the computer 102 to 
communicate with the web server 108. The computer 
102 typically provides a visual interface to the 
WWW and the web server 108 using web browsing 
software such as Internet Explorer (TM) from 
Microsoft Corporation, Redmond, Washington. 

The Specification also teaches at page 13, lines 11-20: 

The telephone network 104 may be the public 
switched telephone network (PSTN) and/or some 
other type of telephone network. For example, 
some embodiments of the invention may allow users 
with a voice over Internet Protocol (IP) phone to 
access the voice portal 110. In the case of voice 
over IP (VoIP) access, the telephone identifying 
information may include any information included 
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with the session setup, e.g. IP addresses, header 
fields, initiator's e-mail address, etc. The 
telephone network 104 is coupled to the telephone 
gateway 107 that allows the voice communications 
and/or touch- tone signals from the telephone 
network 104 to reach the voice portal 110 in 
usable form. Similarly, the telephone gateway 107 
allows audio signals generated by the voice 
portal 110 to be sent over the telephone network 
104 to respective telephones, e.g. the telephone 
100. The telephone network 104 generally 
represents an audio signal carrying network. 

Thus, the Specification teaches exemplary devices that 
those skilled in the art would recognize as being "computers" . 
The fact that various devices could be characterized as 
"computers" does not affect the definiteness of the claims. 
Therefore, Applicants submit that Claims 1-17 are definite and 
particularly point out and distinctly claim the subject matter 
that Applicants regard as the invention. 

Based on the above remarks, Applicants submit that Claims 
1-17 comply with the requirements of 112, first and second 
paragraphs . 

C. Claims 1-3, 5-6, 8-9, and 11-14 are patentable under 3 5 
U.S.C. 103(a) over U.S. Patent 6,065,120 (Laursen) in view of 
U.S. Patent 6,701,366 (Kallas) 

1. Laursen: Overview 

Fig. 2.b of Laursen (shown above) illustrates a layout of a 
typical user account assigned with a mobile phone 106. Col. 7, 
lines 51-53. Each mobile phone is assigned to a device ID 140, 
which can be a phone number or a combination of an IP address 
and a port number. Col. 7, lines 53-55. The device ID 140 is 
further associated with a subscriber number 142 authorized by a 
carrier in the link server 114 as part of the procedures to 
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activate the phone 106. Col. 7, lines 57-60. A corresponding 
account 144 in the database 13 0 is indexed by an account 
structure 143 comprising the subscriber number 142, user 
information 146, a user name 148, and a password 150. Col. 8, 
lines 4-7. As described below, the user name 148 and the 
password 150 control the authentication to enter the account 144 
in the database 130. Col. 8, lines 10-12. 

From a data network perspective, a computer 110 can log on 
to a rendezvous 152 using a URL. Col. 8, lines 12-15. 
According to Laursen, each account in the database 130 is 
exclusively associated with a rendezvous identified by a unique 
URL. Col. 8, lines 15-17. To access the associated account 144 
in the database 13 0, the PC 110 must provide a correct user name 
and password to the rendezvous 152. Col. 8, lines 2 0-26. If 
access is allowed, then the PC 110 can update information stored 
in the account 144. Col. 8, lines 27-28. For example, using 
the PC 110, frequently requested information, e.g. a list of 
stock symbols and a list of URLs of Web servers that provide 
services to the phone 106, can be keyed in. Col. 8, lines 3 0- 
32 . 
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2 . Kallas : Overview 

Figure 10 of Kallas (shown below) illustrates a server 
system 600 and a client system 601 including, respectively, 
telephony applications 606 and 608 for handling telephony 
sessions over networks 21 and/or 12. Col. 11, lines 60-61 and 
col. 11, line 67 to col. 12, line 3. Notably, client system 601 
can store telephony cookies 610, which may have been created in 
telephony sessions established between the client system 601 and 
other terminals. Col. 12, lines 3-6. These telephony cookies 
can be used in future transactions with the telephony server 
system 600 or other terminals. Col. 12, lines 10-13. 
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3 . Applicants' limitations recited in Claims 1-3 , 5-6, 8-9, 
and 11-14 are not taught by Laursen and Kali as. 
Claim 1 recites: 

A method of linking a web based account to a 
phone based account over the world wide web 
(WWW), the method comprising: 

receiving a connection request from a first 
computer on a second computer, the connection 
request formatted as a uniform resource locator 
(URL) , the URL further specifying a linking code 
and a return location, the linking code 
corresponding to an identifier provided by a 
third computer to the first computer and 
identifying the web based account on the third 
computer; 

responsive to one or more messages between 
the first computer and the second computer, 
identifying the phone based account; and 

storing the linking code in the phone based 
account as a cookie . 



Applicants respectfully submit that Laursen fails to 
disclose or suggest the web based account and the phone based 
account recited in Claim 1. The distinction between these 
accounts is critical to understanding the applicability and 
advantages associated with Applicants' invention. 

Specifically, as described in "V. SUMMARY OF CLAIMED SUBJECT 
MATTER", Applicants can efficiently link a web based account to a 
phone based account. Advantageously, this linking avoids the need 
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to directly reveal account information, e.g. username /pas sword, 
about one account to the provider of the other. The linking occurs 
on the web with a user's browser being redirected from the web site 
to the web site of the provider of the voice service. The 
redirection URL will include account -linking information. Once the 
user identifies herself to the web site of the provider of the 
voice service, the linking information can be stored in the user's 
phone account as a cookie. When the user accesses the voice 
service over the phone, her telephone identifying information can 
be used to identify her profile. When she visits the phone 
application corresponding to the web site, the cookie — now 
including linking information — can be passed to the application to 
identify the appropriate web account. 

Laursen fails to disclose or suggest separate web based and 
phone based accounts much less the advantages of linking such 
accounts. As taught in Laursen, a user can access the 
personalized information in an account by using either her 
mobile phone (i.e. the first device, which has a very limited 
computing power) or a PC (i.e. one of the other devices, which 
has a rich user interface). See, for example, col. 2, lines 53- 
57 and col. 3, lines 11-17. Note that Laursen explicitly 
teaches that "user account" and "database" are used 
interchangeably in the description when only one account is 
being addressed. Col. 7, lines 38-40. Laursen further teaches 
that database 130 (Fig. 2.b) can host a plurality of user 
accounts, each designated to an authorized capacity in which 
managed or personalized information is kept. Col. 7, lines 40- 
44. 

The Office Action erroneously characterizes the device ID 
stored in the link server 114 as the phone based account and the 
user name/password in the host server 128 as the web based 
account. These characterizations are contrary to the 
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terminology used by Laursen (see previous paragraph) and 
Applicants. Moreover, these characterizations are not 
consistent with other limitations in the claims. 

For example, if the user name/password is the web based 
account, then the web based account cannot be on the third 
computer (i.e. the Office Action characterizes the host server 
128 as being the second computer and the PC 110 as being the 
third computer) . As another example, if the device ID is the 
phone based account, then the linking code cannot be stored in 
the phone based account (i.e. the Office Action characterizes 
the device ID and subscriber # as being the linking code and 
therefore is somehow stored within a subset of itself) . 
Moreover, as claimed, the linking code corresponds to an 
identifier provided by the third computer to the first computer. 
Therefore, according to the above characterizations in the 
Office Action, the PC 110 would have to provide the mobile phone 
106 with the device ID and subscriber #, which is not taught by 
Laursen. 

Additionally, the URL recited in Claim 1 is received from 
the first computer on the second computer. According to the 
Office Action, which characterizes the mobile phone 106 as the 
first computer, this would mean that the host server 128 
receives the URL from the mobile phone 106. Laursen instead 
teaches that the host server 12 8 can receive a connection 
request in the form of a URL from PC 110. 

Therefore, Applicants traverse the above characterizations 
of Laursen. 

Kallas is characterized as disclosing the use of a telephony 
cookie to store an account name and password. However, Kallas 
notably fails to disclose or suggest storing the linking code 
(which identifies the web based account) in the phone based account 
as a cookie. Thus, even if Laursen and Kallas can be combined 
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(which is arguable) , Applicants' invention is neither disclosed nor 
suggested. 

Because Laursen and Kallas, either individually or in 
combination, fail to disclose or suggest Applicants' recited method 
of Claim 1, Applicants submit that Claim 1 is patentable over these 
cited references. 

Claims 2-3 , 5-6, and 8 depend from Claim 1 and therefore are 
patentable for at least the reasons presented for Claim 1 . 

Moreover, Claim 2 recites in part, "the method further 
comprising sending a message from the second computer to the first 
computer, the message instructing the first computer to send a 
connection request to a computer identified by the URL in the 
return location." According to the characterizations of Laursen in 
the Office Action, the host server 128 would send a message to the 
mobile phone 106 instructing the mobile phone 106 to send a 
connection request to a computer identified by the URL. Laursen 
fails to disclose or suggest this limitation. The Office Action 
indicates that Laursen discloses in col. 14, lines 11-12 that a 
"user sends an activation request from the client, the user has to 
get a URL from the service provider in return in order for the user 
to go to the login screen ... to personalize one's web settings". 
This passage has nothing to do with a client (which is separate 
from the user) or a service provider. Fig. 4 of Laursen confirms 
the characterization in the Office Action is incorrect. As shown 
in Fig. 4, a session request 174 is provided by a client 170 (i.e. 
mobile phone 106, characterized as the first computer in the Office 
Action) to a server 172 (i.e. link server 114, possibly 
characterized as the second computer in the Office Action) . Thus, 
the session request is initiated by client 170. Therefore, based 
on the above remarks, Claim 2 is further patentable over Laursen 
and Kallas. 



19 



09/694 7 797 



Moreover, Claim 3 recites in part, "wherein the method occurs 
entirely in response to a single action" . The Office Action cites 
col. 3, lines 25-27 of Laursen as disclosing this limitation. 
Applicants traverse this characterization. In fact, this passage 
merely teaches "initiating a transaction signal by the thin device 
to the server, the thin device having a client identification 
associated with the user account in the server". Therefore, Claim 
3 is further patentable over Laursen and Kallas. 

Moreover, Claim 8 recites in part, "wherein the return 
location comprises a URL and the cookie is stored in the phone 
based account with a predetermined name, the value of the linking 
code and the domain of the return location" . The Office Action 
indicates that the predetermined name is the name used by the web 
account. As indicated in Fig. 6 of Laursen, this is the username 
"marylee" . The Office Action then erroneously characterizes the 
value of the linking code as "marylee" . Therefore, Claim 8 is 
further patentable over Laursen and Kallas. 

Claim 9 recites: 

A method of accessing a web based account 
over a telephone interface using telephone 
identifying information and a first computer, the 
method comprising: 

identifying a phone account using the first 
computer and the telephone identifying 
information; 

selecting a state associated with the phone 
account using the first computer, the state 
comprising a plurality of cookies; and 

automatically providing a subset of the 
plurality of cookies to the application using the 
first computer, the providing responsive to 
receiving a request over the telephone interface 
to initiate an application on a second computer, 
wherein the subset of the plurality of cookies 
includes at least one cookie including a linking 
code, the linking code identifying a web account 
to the second computer. 
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Applicants submit that Laursen and Kallas fail to disclose or 
suggest the state associated with the phone account and the linking 
code identifying the web account. The Office Action characterizes 
the user name 148 and password 150 as the "state", the device ID 
140 as the "phone account", and user credential information as the 
"linking code" . Applicants traverse this characterization. 
Specifically, Laursen teaches that such user credential information 
is in fact the user name and password. Col. 14, lines 9-28. 
Therefore, the Office Action fails to distinguish between the 
recited state and linking code. 

As recited in Claim 9, the state comprises a plurality of 
cookies associated with the phone account . During the step of 
automatically providing, only a subset of the plurality of cookies 
is used, wherein that subset includes at least one cookie including 
a linking code. That linking code identifies the web account to 
the second computer. Because both Laursen and Kallas fail to 
disclose or suggest the state associated with the phone account and 
the linking code identifying the web account, Applicants submit 
that Claim 9 is patentable over these references. 

Claims 11-13 depend from Claim 9 and therefore are patentable 
for at least the reasons presented for Claim 9 . 

Moreover, Claim 11 recites in part, "further comprising 
automatically removing the at least one cookie including the 
linking code from the plurality of cookies after the automatically 
providing" . The Office Action impermissibly ignores the limitation 
regarding the cookie including the linking code (which identifies a 
web account to the second computer) . Therefore, Claim 11 is 
further patentable over Laursen and Kallas. 

Moreover, Claim 12 recites in part, "wherein responsive to 
receiving the at least one cookie including the linking code, the 
application capable of accessing information associated with the 
related web account" . The Office Action erroneously characterizes 
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a phone account and a web account as being in account entry 152. 
Therefore, Claim 12 is further patentable over Laursen and Kallas. 
Claim 14 recites: 

An apparatus for linking a web based account 
to a phone based account over the world wide web 
(WWW) , the apparatus comprising: 

means for receiving a connection request 
from a first computer, the connection request 
formatted as a uniform resource locator (URL) , 
the URL further specifying a linking code and a 
return location, the linking code corresponding 
to an identifier provided by a third computer to 
the first computer and identifying the web based 
account on the third computer; 

means for communicating with the first 
computer to identify the phone based account; and 

means for storing the linking code in the 
phone based account as a cookie. 

The Office Action indicates that the phone 106 is 
characterized as the first computer, and either server 1 or server 
2 (see Fig. 2. a) is characterized as the third computer. However, 
the connection request from phone 106 is not formatted as a URL. 
Moreover, the URL taught by Laursen teaches nothing about 
specifying a linking code and a return location, wherein the 
linking code corresponds to an identifier provided by the third 
computer to the first computer and identifying the web based 
account on the third computer. Laursen also teaches nothing 
regarding the means for communicating with the first computer to 
identify the phone based account or the means for storing the 
linking code in the phone based account. Kallas fails to remedy 
the deficiencies of Laursen with respect to Claim 14. 

Because Laursen and Kallas fail to disclose or suggest 
numerous limitations of Claim 14, Applicants submit that Claim 14 
is patentable over these references. 



22 



09/694, 797 

D. Claim 4 is patentable under 35 U.S.C. 103(a) over Laursen 
in view of Kallas and further in view of Safari Tech Books 
Online Java 2 in 21 Days (Java2) . 

1. Laursen and Kallas: Overview (see Section C) 

2 . Java 2 : Overview 

Java2 teaches, among other subjects, how to handle mouse 
clicks . 

3 . Applicants 7 limitations recited in Claim 4 are not taught 

by Laursen, Kallas, and Java 2 . 

Claim 4 depends from Claim 1 and therefore is patentable for 
at least the reasons presented for Claim 1. Notably, Java2 fails 
to remedy the deficiency of Laursen and Kallas with respect to 
Claim 1. 

Claim 4 recites in part, "wherein the single action comprises 
a mouse click" . Nothing in Laursen or Kallas teaches this 
limitation. Java2 fails to remedy this deficiency as well. 
Therefore, Applicants submit that Claim 4 is further patentable 
over Laursen, Kallas, and Java2 . 

E. Claims 7 and 15-17 are patentable under 35 U.S.C. 103(a) 
over Laursen in view of Kallas and further in view of Google's 
"A Generalized Wallet Architecture" (Google) . 

1. Laursen and Kallas: Overview (see Section C) 

2 . Google : Overview 

Google teaches a generalized wallet architecture. 
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3 . Applicants ' limitations recited in Claims 7 and 15-17 are 

not taught by Laursen, Kallas, and Google. 

Claim 7 depends from Claim 1 and therefore is patentable for 
at least the reasons presented for Claim 1. Notably, Google fails 
to remedy the deficiency of Laursen and Kallas with respect to 
Claim 1. 

Moreover, Claim 7 recites in part: 

wherein the URL formatted in the connection 
request further includes a wallet indicator, the 
wallet indicator provided by the third computer 
and indicating that the third computer will share 
commerce related information relating to the web 
account with the second computer. 

Laursen, Kallas, and Google each individually fail to teach 
that a URL can include a wallet indicator. Applicants note that 
Laursen fails to teach anything on allowing consumers to easily 
pay for goods and services electronically. Because no 
suggestion for electronic commerce is provided in Laursen, 
combining this reference with Kallas and Google is clearly 
hindsight. Therefore, Applicants submit that Claim 7 is further 
patentable . 

Claim 15 recites: 

A method of obtaining a customer information 
over a telephone interface using telephone 
identifying information and a first computer, the 
method comprising: 

identifying a phone account using the first 
computer and the telephone identifying 
information; 

selecting a state associated with the phone 
account using the first computer, the state 
comprising a plurality of cookies; 

selecting at least one of the plurality of 
cookies comprising a wallet indicator, the wallet 
indicator comprising an URL for obtaining 
customer information in a web account from a 
second computer; and 
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using the URL to obtain the customer 
information from the second computer. 

Laursen, Kallas, and Google, individually or in combination, fail 
to teach that a cookie can include a wallet indicator. 
Additionally, Laursen, Kallas, and Google, individually or in 
combination, also fail to teach that the wallet indicator can 
include a URL. Applicants note that Laursen fails to teach 
anything on allowing consumers to easily pay for goods and services 
electronically. Because no suggestion for electronic commerce is 
provided in Laursen, combining this reference with Kallas and 
Google is clearly hindsight. Based on these reasons, Applicants 
submit that Claim 15 is patentable. 

Applicants note that the Office Action fails to indicate a 
rejection of Claims 16 and 17 based on the cited references. 
Applicants assume that Claims 16 and 17 are further rejected 
because of their dependency from Claim 15 and respond accordingly 
herein. 

Claims 16-17 depend from Claim 15 and therefore are patentable 

for at least the reasons presented for Claim 15. 

Moreover, Claim 16 recites in part: 

wherein responsive to the using, a 
predetermined amount is paid by the operator of the 
first computer to the operator of the second 
computer. 

Applicants submit that Laursen, Kallas, and Google, either 
individually or in combination, fail to disclose or suggest this 
limitation. Therefore, Applicants submit that Claim 16 is further 
patentable over the cited references. 

Moreover, Claim 17 recites in part: 

wherein there is at least one of the plurality 
of cookies comprising a linking code and wherein 
the using further comprises sending a hypertext 
transfer protocol (HTTP) request to the URL that 
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includes the linking code and receiving back the 
customer information. 

Applicants submit that Laursen, Kail as, and Google, either 
individually or in combination, fail to disclose or suggest this 
limitation. Therefore, Applicants submit that Claim 17 is further 
patentable over the cited references. 

F. Claim 10 is patentable under 35 U.S.C. 103(a) over Laursen 
in view of Kallas and further in view of Safari Tech Books 
Online "Using HTML 4, XML, and Java 1.2" (Safari) . 

1. Laursen and Kallas: Overview (see Section C) 

2 . Safari : Overview 

Safari teaches using SSL protocol to provide data encryption 
and ensure security. 

3 . Applicants' limitations recited in Claim 10 are not taught 

by Laursen, Kallas, and Safari. 

Claim 10 depends from Claim 9 and therefore is patentable for 
at least the reasons presented for Claim 9. Notably, Safari fails 
to remedy the deficiency of Laursen and Kallas with respect to 
Claim 9. 
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C, CONCLUSION 

For the foregoing reasons, it is submitted that the 
Examiner's rejections of Claims 1-17 are erroneous, and reversal 
of these rejections is respectfully requested. 
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VIII. CLAIMS APPENDIX 

1. (Original) A method of linking a web based account to a 
phone based account over the world wide web (WWW) , the method 
comprising : 

receiving a connection request from a first computer on a 
second computer, the connection request formatted as a uniform 
resource locator (URL) , the URL further specifying a linking 
code and a return location, the linking code corresponding to an 
identifier provided by a third computer to the first computer 
and identifying the web based account on the third computer; 

responsive to one or more messages between the first 
computer and the second computer, identifying the phone based 
account ; and 

storing the linking code in the phone based account as a 
cookie . 

2. (Original) The method of claim 1, wherein the return 
location comprises a URL, the method further comprising sending 
a message from the second computer to the first computer, the 
message instructing the first computer to send a connection 
request to a computer identified by the URL in the return 
location . 

3. (Original) The method of claim 1, wherein the method 
occurs entirely in response to a single action. 

4. (Original) The method of claim 3, wherein the single 
action comprises a mouse click. 

5. (Original) The method of claim 1, wherein the first 
computer comprises a computer operated by an individual and the 
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second computer operated by a legal entity that supports access 
to the phone based account for the individual via a telephone 
interface . 

6. (Original) The method of claim 1, wherein the second 
computer and third computer are operated by different legal 
entities . 

7. (Original) The method of claim 1, wherein the URL 
formatted in the connection request further includes a wallet 
indicator, the wallet indicator provided by the third computer 
and indicating that the third computer will share commerce 
related information relating to the web account with the second 
computer . 

8. (Original) The method of claim 1, wherein the return 
location comprises a URL and the cookie is stored in the phone 
based account with a predetermined name, the value of the 
linking code and the domain of the return location. 

9. (Original) A method of accessing a web based account 
over a telephone interface using telephone identifying 
information and a first computer, the method comprising: 

identifying a phone account using the first computer and 
the telephone identifying information; 

selecting a state associated with the phone account using 
the first computer, the state comprising a plurality of cookies; 
and 

automatically providing a subset of the plurality of 
cookies to the application using the first computer, the 
providing responsive to receiving a request over the telephone 
interface to initiate an application on a second computer, 
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wherein the subset of the plurality of cookies includes at least 
one cookie including a linking code, the linking code 
identifying a web account to the second computer. 

10. (Original) The method of claim 9, wherein the 
automatically providing occurs over a communication channel 
encrypted according to one or more of a secure sockets layer 
(SSL) protocol and a transport layer security (TLS) protocol. 

11. (Original) The method of claim 9, further comprising 
automatically removing the at least one cookie including the 
linking code from the plurality of cookies after the 
automatically providing. 

12. (Original) The method of claim 9, wherein responsive to 
receiving the at least one cookie including the linking code, 
the application capable of accessing information associated with 
the related web account. 

13. (Original) The method of claim 9, wherein subsequent to 
receiving the at least one cookie including the linking code, 
the application receives a string, the string corresponding to 
single key DTMF sequence of a password for the related web 
account, and wherein the application capable of accessing 
information associated with the related web account using the 
string . 

14. (Original) An apparatus for linking a web based account 
to a phone based account over the world wide web (WWW) , the 
apparatus comprising : 

means for receiving a connection request from a first 
computer, the connection request formatted as a uniform resource 
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locator (URL) , the URL further specifying a linking code and a 
return location, the linking code corresponding to an identifier 
provided by a third computer to the first computer and 
identifying the web based account on the third computer; 

means for communicating with the first computer to identify 
the phone based account; and 

means for storing the linking code in the phone based 
account as a cookie. 

15. (Previously Presented) A method of obtaining a customer 
information over a telephone interface using telephone 
identifying information and a first computer, the method 
comprising : 

identifying a phone account using the first computer and 
the telephone identifying information; 

selecting a state associated with the phone account using 
the first computer, the state comprising a plurality of cookies; 

selecting at least one of the plurality of cookies 
comprising a wallet indicator, the wallet indicator comprising 
an URL for obtaining customer information in a web account from 
a second computer; and 

using the URL to obtain the customer information from the 
second computer. 

16. (Previously Presented) The method of claim 15, wherein 
responsive to using the URL, a predetermined amount is paid by 
the operator of the first computer to the operator of the second 
computer. 

17. (Previously Presented) The method of claim 15, wherein 
there is at least one of the plurality of cookies comprising a 
linking code and wherein using the URL further comprises sending 
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a hypertext transfer protocol (HTTP) request to the URL that 
includes the linking code and receiving back the customer 
information. 
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IX. EVIDENCE APPENDIX 



None 



X. RELATED PROCEEDINGS APPENDIX 

None 
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